home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5183 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.3 KB
  1. Path: news.cs.ucla.edu!twinsun!not-for-mail
  2. From: eggert@twinsun.com (Paul Eggert)
  3. Newsgroups: comp.lang.c,comp.lang.c++,gnu.gcc.help,gnu.g++.help,comp.os.msdos.djgpp
  4. Subject: Re: float != float and floats as return types
  5. Date: 2 Feb 1996 12:57:08 -0800
  6. Organization: Twin Sun Inc, El Segundo, CA, USA
  7. Message-ID: <4ettr4$al5@der.twinsun.com>
  8. References: <4ej9lb$mpc@fu-berlin.de> <4elnjj$er4@server2.rz.uni-leipzig.de>     <4eqc7l$ugh@godzilla.zeta.org.au> <4eqtu3$ddo@der.twinsun.com> <TANMOY.96Feb1164022@qcd.lanl.gov>
  9. NNTP-Posting-Host: der.twinsun.com
  10.  
  11. tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya) writes:
  12.  
  13. > I do not agree with this interpretation, as the footnote (technically,
  14. > not part of the standard) clarifies: an assignment and cast both must
  15. > truncate the result to the required precision.
  16.  
  17. Sorry, that footnote doesn't clarify matters.  All the footnote says
  18. is that the required conversions must be performed.  In the example
  19. we're talking about, there's no conversion to be performed, since
  20. both sides of the assignment have `float' type.
  21.  
  22. Furthermore, even if there is a conversion, I don't see where the standard
  23. requires that excess precision be discarded.  All the standard requires is
  24. that the result be ``represented exactly''; it doesn't say what it means
  25. by this, and an implementation that keeps excess precision is certainly
  26. representing _its_ result exactly.  The standard explicitly licenses
  27. excess precision, and never explicitly (or implicitly, as far as I can
  28. see) requires excess precision to be discarded.
  29.  
  30. Also please see ANSI C 3.3.4, which says ``A cast that specifies no
  31. conversion has no effect on the type or value of the expression'';
  32. this means that an implementation with extra precision is not allowed
  33. to discard it because of a cast of float to float.  It is natural to
  34. assume that assignment of float to float can behave similarly to a cast.
  35.  
  36. I realize that the standard is muddled in this area -- for example, the
  37. Rationale contradicts it, and I've been told that the C Standard committee
  38. may amend 3.3.4 because of the problem with floating point casts
  39. (surely an implementation should be allowed to discard excess precision
  40. whenever it wants to).
  41.  
  42. That being the case, I think it wise for users not to rely on the fine
  43. points here, and my advice to the GCC implementers is to hold off on
  44. changing GCC's behavior until the C Standard committee acts.
  45.